home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
EnigmA Amiga Run 1997 April
/
EnigmA AMIGA RUN 17 (1997)(G.R. Edizioni)(IT)[!][issue 1997-04][EAR-CD].iso
/
EARCD
/
docs
/
hyper
/
ZCD.lha
/
Listino
/
Announces
/
Graffiti.txt
< prev
next >
Wrap
Text File
|
1996-06-17
|
18KB
|
479 lines
Reply auf User fer@inrete.it am 04.01.1996 21:59:16
>Dear Sir,
>
>One my customer has told me about your gfx card for A1200.
>Please give me every information about it, I could be interest
>to distribute it in Italy.
>
In fact, the card is not only for the A1200, but for all Amigas. As I heard
on the developer conference in Köln, Germany in November, most Italians
have the A500, so you'll be pleased to hear that it works fine with ist. At
the end of this message I'll send you the "short-data" and the
developer-manual.
Just a word for the developer manual: I decided not to make a "lores" and a
"Hires" version, there is only one version that can display every
resolution.
--
Jens Schönfeld
--- cut here (short info, for advertising) ---
Some technical information about the Graffiti card...
- works with _any_ Amiga:
A500/1200/2000/2500/3000/3000T/4000/4000T
Even A 1000, CDTV, SX-32, SX-1 and A600/A500 plus have been successfully
tested!
- 256 out of 262144 colours at a time
- lores Output on OCS/ECS Amigas, Hires on AA Amigas. Overscan and
interlace supported!
- simply plugs to the RGB-port of the Amiga. No need to open
the Computer! (RGB 15Khz Monitor required).
If not activated, standard Amiga Graphics is displayed.
- chunky graphics for fast animation sequences/ texture mapping games
Chunky means: one byte in memory represents one pixel on screen.
- programmers only have to switch on 4 bitplanes => 4 DMA channels
=> full 7MB/sec on AA Amigas!
(compared to 3.5 to 5 MB/s on 8bpls lores!)
- faster display by reducing the resolution:
The Graffiti supports half and quarter-lores (160 an 80 pixels/line)
without additional CPU or blitter time for expanding the pixels!
- uses chipmem to store graphics, no memory on the card (that's why it's
this cheap!)
- sales price 149 DM (about 700 DKK, 105 US$)
- software:
+ external video driver for shapeshifter shipped with the card
+ IFF/GIF/JPEG viewers
+ AVI Video player
+ doom-style games
+ Graffiti support CD released every 3 to 6 months:
only DM 9,95 (40 DKK, 7 US$)
- for the developer Manual call Nostalgic BBS +49 241 86985
Login: Graffiti, Password: Graffiti
(sorry, BBS Language is German!)
------------ cut again (short info) -----------
------- cut (developer manual) ------
Earth, Germany, Aachen, September '95
Documentation for the Graffiti Gfx card for OCS/ECS/AGA Amigas
"Someone said, that programmers can't make readable manuals.
Here's one from a hardware designer, so don't wonder if it's
a complete disaster".
1. What it does
Graffiti changes the Amiga bitplaned graphics into a chunky
pixel mode. I.e. one byte in memory represents a single
pixel. The value of a byte selects it's colour. The colour
palette is 256 out of 262144 at a time. Possible
resolutions are 640x256 (hires version only), 320x256,
160x256 and 80x256. In each mode, 256 colours are
available, interlacing doubles the vertical resolution.
2. How to connect
The Graffiti card plugs into the RGB port of the Amiga. The
monitor must be connected to the RGB output of the Graffiti,
there's no need to open the computer. See appendix A for
Dip switch settings.
3. System requirements, compatibility, limits
The hardware has been successfully tested with all known
Amiga models: A500, A600, A1200, A2000, A2500, A3000, Amiga
CDTV and the A4000. Even "the" Amiga (later called the
Amiga 1000) has been sucsessfully tested. For displaying
the output, a standard 15khz RGB-Monitor like the commodore
1081 and 1084 models is required. The commodore A2024 is
not supported. The Graffiti is PAL and NTSC compatible.
For full speed advantages, AGA Chipset or the A3000 are
recommended. For more speed, accelerator cards with
burstmode fastmem are recommended.
Due to the limited bandwidth of the chipmemory, the frame
rate of a motion sequence is limited. At about 7MB/s on
AGA-chipsets using 4 Bpls hires, with longword-access about
74 frames/s can be transferred - more than required. Using
word access, it's reduced to about 37 frames/s, and with
byte access only 18 frames/s are possible, so setting up
longwords in the processor registers or in fastmem is
recommended. (Numbers assuming a 384x256 window). Using
the 160x256 pixel mode of the hires version or the 80x256
pixel mode, the chunky buffer is completely linear, so you
can access four pixels in a row with a single longword move.
Colour #0 of the Graffiti (external palette, see further
down) must always be set to black (R=G=B=0), because of some
monitors trying to adapt to a 0- level after Hsync. This
causes vertical brightness fading in the first lines if
colour#0 is not set to black. It's different on different
monitors, so this cannot be used as an effect.
4. Activating the card, word definitions
Lores version:
To activate the card, switch to a hires screen at 1, 2 or 4
bitplanes, depending on the resolution you want to display.
Set the genlock audio bit to 1, otherwise the standard Amiga
bitplaned graphics will be displayed.
Hires version:
To activate the card, switch to a hires or SHires screen at
1, 2 or 4 bitplanes, depending on the resolution you want to
display. Set the genlock audio bit to 1, otherwise the
standard Amiga bitplaned graphics will be displayed.
The Graffiti card has got it's own color palette that is
called "external palette" from now on. The Amiga-palette
that is set in denise/lisa will be called "internal
palette".
While displaying the chunky pixel mode, the internal palette
must be set to one of the following: (no matter what
version you are programming)
4 bitplanes: (320 pixel/line at hires, 640 pixel/line at SHires)
R G B
Colour #0 0 0 0
Colour #1 0 0 1
Colour #2 0 0 8
Colour #3 0 0 9
Colour #4 0 8 0
Colour #5 0 8 1
Colour #6 0 8 8
Colour #7 0 8 9
Colour #8 8 0 0
Colour #9 8 0 1
Colour #10 8 0 8
Colour #11 8 0 9
Colour #12 8 8 0
Colour #13 8 8 1
Colour #14 8 8 8
Colour #15 8 8 9
2 bitplanes: (160 pixel/line at hires, 320 pixel/line at SHires)
R G B
Colour #0 0 0 0
Colour #1 0 0 9
Colour #2 8 8 0
Colour #3 8 8 9
1 bitplane: (80 pixel/line at hires, 160 pixel/line at SHires)
R G B
Colour #0 0 0 0
Colour #1 8 8 9
The See appendix A for softscroll-values and Dip-Switch
settings.
While displaying a chunky pixel mode, the internal palette
and the X- Offset of the bitplanes must not be changed,
otherwise the Graffiti does undefined things (don't worry,
it won't toast your hamster).
Choosing 4 bitplanes hires or 2 bitplanes SHires sets the
Graffiti to 320x256 pixel. Setting up 2 bitplanes hires or
1 Bitplane SHires selects 160x256 pixel, and a single
bitplane hires selects the 80x256 mode. The highest
resolution available is 4 Bitplanes SHires, resulting in a
display of 640x256 pixel. The Graffiti is
overscan-compatible, so up to 768 pixel and more than 512
lines are possible (depends on PAL or NTSC modes, interlaced
or non-interlaced).
5. Initializing the card
After power-up the RamDAC chip on the Graffiti card is in an
undefined state. It must be initialized by a sequence of
commands sent in the Graphics data. After a VSync the
Graffiti card is in command mode, meaning the bitplane data
is interpreted as commands, not as Gfx data. In command
mode, the Graffiti shows a black screen, so transferring the
palette is invisible for the user. Note that when
interlacing, a VBlank splits the two half screens, so you
have to send start-Graphic commands every half frame.
Commands can only be sent within 4 Bitplanes Hires with the
corrosponding internal palette set.
A command is composed of two bytes, the command byte and the
parameter byte. There are 6 commands:
0 NOP No operation, parameter is ignored.
4 Set colour Parameter sets colour to be set
next.
5 Set Mask register Parameter sets the pixel read mask
register (should be set to #255)
6 Set RGB value sets the RGB values of the colour
that is defined by the 4-command.
This command must be executed three
times in a row, first to set the
Red value, then to set the green
value, then to set the blue value.
Values must be from 0 to 63, the
upper two bits are ignored.
7 Set read position not supported, for debugging
purposes.
8 Start lores Ends the command sequence and
starts lores graphics (use this
command for hires screens).
24 Start hires Ends the command sequence and
starts hires output (use this
command for SHires screens). This
command is only available with the
hires version, it's handeled like
the 8 command on the lores version.
First command to be executed is byte 0 in bitplane 0. The
corrosponding parameter is located in bitplane 1, byte 0.
The second command to be executet is byte 0 in bitplane 2,
the corrosponding parameter is byte 0 in bitplane 3. The
third command is byte 1 in bitplane 0, the parameter is
located in byte 1 of bitplane 1. Example:
Assuming the base addresses of the four bitplanes are
located in (a0) to (a3):
move.b #5,(a0)+ ; set pixel read mask register
move.b #255,(a1)+ ; to 255
move.b #0,(a2)+ ; NOP
move.b #0,(a3)+ ; parameter is ignored - can ne any
; value.
The pixel read mask register can be used for effects, see
chapter 8 for suggestions. This should be the first command
in a palette sequence.
Addressing with postincrement and arranging in Blocks of
four sequential move.b's has been proved to be very
distinct. The following sequence sets colour #0 to black
(R=G=B=0):
move.b #4,(a0)+ ; set COLOUR #
move.b #0,(a1)+ ; 0 next.
move.b #6,(a2)+ ; Set red value
move.b #0,(a3)+ ; to 0.
move.b #6,(a0)+ ; Set green value
move.b #0,(a1)+ ; to 0.
move.b #6,(a2)+ ; Set blue value
move.b #0,(a3)+ ; to 0.
The next example sets color #23 to a light blue:
move.b #4,(a0)+ ; set COLOUR #
move.b #23,(a1)+ ; 23 next.
move.b #6,(a2)+ ; Set red value
move.b #0,(a3)+ ; to 0.
move.b #6,(a0)+ ; Set green value
move.b #0,(a1)+ ; to 0.
move.b #6,(a2)+ ; Set blue value
move.b #63,(a3)+ ; to 63.
You don't have to worry if a command sequence crosses a
scanline, this can be handled by the Graffiti card. This
enables the programmer to set the palette using only the
postincrement-moves. To reduce the number of lines for
transferring the palette, the complete overscan can be used.
The last command in the palette sequence depends on the
screenmode you want to display, and on the version you're
programming. If you are using the lores version, the last
command is always 8:
move.b #8,(a0)+ ; Start lores Graphics
move.b #0,(a1)+ ; This byte will be displayed as
; graphics (Black in this case)
Using the 8 command, graphics can be started within a line,
which is not possible with the 24 command:
move.b #24,(a0)+ ; Start Hires Graphics
move.b #0,(a1)+ ; This byte must be 0, otherwise
; random colours will be displayed
The rest of the bytes in the line must be set to 0 if the 24
command is not the last in a line.
6. Using the chunky mode
Referring to the Graphics bitplanes I assume that the
bitplanepointers now point to new locations.
If you are using 4 bitplanes, the graphics are displayed
this way:
1st pixel is byte 0 in bitplane 0
2nd pixel is byte 0 in bitplane 1
3rd pixel is byte 0 in bitplane 2
4th pixel is byte 0 in bitplane 3
5th pixel is byte 1 in bitplane 0
6th pixel is byte 1 in bitplane 1
7th pixel is byte 1 in bitplane 2
8th pixel is byte 1 in bitplane 3
9th pixel is byte 2 in bitplane 0
and so on. The value of a byte represents the colour of the
pixel. As you can see, the bitplanes are displayed in the
sequence 0-1-2-3-0-1-2-3.
Using 2 bitplanes, the displaying sequence is
0-1-0-1-0-1..., in other words:
1st pixel is byte 0 in bitplane 0
2nd pixel is byte 0 in bitplane 1
3rd pixel is byte 1 in bitplane 0
4th pixel is byte 1 in bitplane 1
5th pixel is byte 2 in bitplane 0
6th pixel is byte 2 in bitplane 1
7th pixel is byte 3 in bitplane 0
8th pixel is byte 3 in bitplane 1
9th pixel is byte 4 in bitplane 0
Using a single bitplane, the bytes are completely linear
aligned, no further explanation necessary, is it?
7. Speeding up
I'd like this chapter to be discussed, that's why I posted
the manual to alt.sys.amiga.demos. I'm no programmer at
all, all I can do is some move's, 6502 assembler and boolean
equations, so don't take my suggestions too seriously.
The aim of the design was to speed up games and animation
players, because bitplaned graphics take more CPU time to
modify than chunky graphics. However, optimizing your code
is still necessary, because fast CPUs are still no standard
in the Amiga world. One main problem ist the bandwidth of
the chipmem, which is discussed in chapter 3.
When playing back animation sequences, triple buffering can
speed up, because you don't have to wait for the displaying
hardware to display your already-made second picture, which
is necessary if you only use two buffers. Using three
buffers, you can start drawing the second picture after the
one being displayed, so your CPU is not idle. If your
routine sometimes takes several frames to render a frame,
and sometimes only some scanlines, more buffers could be
useful, you have to find this out on your own.
If you are using more than one bitplane, horizontal
rendering takes much more time than vertical rendering,
because you have to spread the data over the bitplanes. If
you start four (or two, depending on the number of bitplanes
you're using) vertical renderers, each of them can work in
its own bitplane, so spreading the data is not necessary.
On OCS/ECS machines 4 bpls hires kills bandwidth on chipmem,
so turn off the DMA where you can!
8. Suggestions for effects
Hardware sprites can be used as objects, but their
X-position must be set in 8-hires-pixel-steps (lores
diaplay) or 8-SHires-pixel-steps (hires display using SHires
bitplanes). As you can see, this is only possible on
AGA-machines, the OCS/ECS only allows lores sprites, which
is useless for the Graffiti. Set the same number of
bitplanes and the same internal colour palette for the
sprites. The Graffiti GFX card cannot tear sprite data
apart from bitplane data, so sprites use the same external
colour palette. If you choose a 16-colour sprite to be 16
pixel wide, the output will be 8 pixel wide. You can also
use sprites to increase resolution temporarily: If you're
using 2 hires-bitplanes (160 pixel output), a 16- colours
sprite will display in standard lores.
Problem: The sprite background (the bytes that are covered
by the sprite) must be empty, i.e. before you can display a
sprite, you have to clear the area it will cover, so this is
only useful for small moving objects without a background.
Fading in/out
I can imagine that 18 bit colour fading looks pretty neat.
Due to the fact that the external palette is transferred as
GFX data, you can use a single move into the copperlist to
choose another colourtable. If you have pre- calculated
fading tables, this won't take too much CPU time :-).
Hazy picture (Cmdr. La Forge, your visor is dead!)
Swapping bitplanes causes pixels to be swapped. If you swap
bitplanes 0 and 2 of a 4-bitplane-display every 2nd line,
the picture will look hazy as if your glasses are smutty.
Changing the bitplanes to be swapped every frame will look
like picture noise. You can underline this effect by
switching to a grey scale palette. All this can be done by
copper - hey, I could do that, too!
The Pixel read mask register can be used to reduce the
maximum # of colours to be displayed. This is achieved by
gating the bytes in the bitplanes with the contents of the
pixel read mask register. The operation is a bitwise
logical ANDing. The pixel masking operation can be used to
alter the displayed colours without changing the contents of
the external palette. The effect of this operation is to
partition the external palette into a number of colour
planes. This can be used for flashing objects, animation or
overlays - without software overhead.
What about dot-landscapes? Setting a dot means a single
move..
It's up to you!
Appendix A: Dip switch settings and softscroll-offsets
To be compatible to every chipset there is, the programmer
has do detect on which machine his program runs on. You can
find the version numbers of the chips in some variables of
the gfxbase.h (I'd be pleased if someone made a chapter out
of this sentence!).
AGA machines:
Dip 1 = on, Dip 2 = off,
Softscroll = 0
OCS Machines (any Agnus with OCS Denise):
Dip 1 = off, Dip 2 = off,
Softscroll = 1 (1 lores-pixel to the right)
ECS Denise with 8372A Agnus:
Dip 1 = on, Dip 2 = off,
Softscroll = 1 (1 lores-pixel to the right)
ECS Denise with 8372B Agnus (A3000):
Dip 1 = off, Dip 2 = off,
Softscroll = 1 (1 lores-pixel to the right)
Other combinations have been succesfully tested, but I don't
remember the Dip settings by now, they'll be in the next
version of the manual.
----- cut again (developer manual) -----